Date: Fri, 4 Mar 94 03:09:59 PST 

From: Info-Hams Mailing List and Newsgroup <info-hams@ucsd.edu> 
Errors-To: Info-Hams-Errors@UCSD.Edu 

Reply-To: Info-Hams@UCSD.Edu 

Precedence: Bulk 

Subject: Info-Hams Digest V94 #234 

To: Info-Hams 


Info-Hams Digest Fri, 4 Mar 94 Volume 94 : Issue 234 


Today's Topics: 
ARRL DX Bulletin #42 - February 28, 1994 
Easy to get 6:1 balun? 
Errors in TNC2 firmware??? 
FT-530 vs TH-78A 
Help!!! Please :) 
Medium range point-to-point digital links 
Nude Radio Amateurs 


Send Replies or notes for publication to: <Info-Hams@UCSD.Edu> 
Send subscription requests to: <Info-Hams-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Info-Hams Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/info-hams". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: Wed, 2 Mar 1994 20:16:02 MST 

From: ihnp4.ucsd.edu!swrinde! gatech!newsxfer.itd.umich.edu!nntp.cs.ubc.ca!alberta! 
veémgs!usenet@network.ucsd.edu 

Subject: ARRL DX Bulletin #12 - February 28, 1994 

To: info-hams@ucsd.edu 


ZCZC AE10 

QST de W1AW 

DX Bulletin 12 ARLDO12 

>From ARRL Headquarters 
Newington CT February 28, 1994 
To all radio amateurs 


SB DX ARL ARLDO12 
ARLDO12 DX update 


Documentation has been received and approved for the following 
operations: 


Call: Operations Beginning (mm/dd/yy): 


3V8W 07/17/93 CW only 7, 14, 18, 21Mhz 
7Q7IA 05/07/90 

807BX 12/07/93 
8R1/KD4GMV 01/11/94 
8R1/KK4WW 01/11/94 
9M2/DK7PE 05/17/93 

A35CW 01/06/94 

FS/W20M 12/01/93 
H44/DK7PE 12/13/93 
HI8/7073A 07/19/91 

P29VCW 05/18/93 

T7/DK7PE 05/10/93 144 Mhz 
VKOMM 09/18/93 
V51/7Q7J9A 07/18/91 

V63MV 12/23/92 

YIOAXX 12/23/93 

ZD9SXW 09/29/93 

ZK1ACW 01/17/94 

ZVOASN 01/01/94 

NNNN 


James J. Reisert Internet: reisert@wrksys.enet.dec.com 


Digital Equipment Corp. UUCP: ...decwrl!wrksys.enet.dec.com!reisert 
146 Main Street - MLO3-6/C9 Voice: 508-493-5747 
Maynard, MA 01754 FAX: 508-493-0395 


Date: Thu, 3 Mar 1994 15:01:01 GMT 

From: netcomsv!netcomsv! bongo! julian@decwrl.dec.com 
Subject: Easy to get 6:1 balun? 

To: info-hams@ucsd.edu 


In article <wier-020394203159@198.213.12.252> wier@merlin.etsu.edu (Bob Wier) 
writes: 

>Having a scanner with a 50 ohm input, I decided to try 

>a tv antenna (yagi) as a directional antenna. Small snag - 

>I got a 300 to 75 ohm transmormer, fed it to the 50 

>ohm input and it seemed to work reasonably well, but 

>I'd still like to get a better match. Does anyone know 

>where you can come up with a 300 ohm balanced to 50 

>ohm unbalanced (coax) transformer which would be good 


>up to about 1Ghz? 


You are making a rash assumption that the input impedance of 
your scanner is 50 Ohms across its range. Trust me, it isn't. 


If your antenna is not working optimally with your scanner, 
there are many things that could be wrong besides the balun and coax 
impedance. Loss in the balun at frequencies of interest may be one, so 
get the best TV/UHF balun you can find. The antenna may not be optimum 
at the frequencies of interest. 


Feeding your scanner with 75 Ohm coax won't make any 
difference that you will notice. Feeding it with a long run of cheesy 
coax will make a difference. 


Getting your antenna up high and in the clear will make a 
difference. 


Julian Macassey, N6ARE julian@bongo.tele.com Voice: (310) 659-3366 
Paper Mail: Apt 225, 975 Hancock Ave, West Hollywood, California 90069-4074 


Date: 28 Feb 94 06:25:08 GMT 

From: nprdc!ihnp4.ucsd.edu!ucsnews!sol.ctr.columbia.edu!howland.reston.ans.net! 
agate! library.ucla.edu!csulb.edu!tern.csulb.edu!usenet@network.ucsd.edu 
Subject: Errors in TNC2 firmware??? 

To: info-hams@ucsd.edu 


I have recently been experimenting with TNC2 clones and had run 
across two peculiar "bugs" in the firmware of an MFJ 1278, and 
a tiny TNC2. 


The first problem relates to when the TNC2 sends to the computer 
the "Change incoming stream" command ("|B" to switch to stream B, 
for example). It seems that when in command mode, the TNC set the 
output stream to be equal to the input stream whenever it sends 
the "cmd:" prompt (if, of course. the output stream was set to 
something else previously). So it you are in command mode in stream 
A, and send a "|b" to set the input stream to B, and press Enter, 
the tne will respond with "|Bcemd:" to tell that the output stream 
should now ALSO be set to stream B. The problem is this: The stream 
switch is sent JUST before sending the cmd: prompt. So if you are on 
stream A in command mode, and type "|bcst<CR>" to set the input to 
stream B and get the status of all streams, the tnc will send the 
results, THEN the |B, then the new cmd: prompt. SO, the output of 


the cst request made on stream B will be sent to stream A. In fact, 
the results will show that the input stream is B, while the output 
stream is A! Of course, if you type another "cst<CR>", the results 
will be sent to the proper stream, because it has already been 
corrected. Do all TNC2's exhibit this feature? 


The second problem is more major. I seems that when I am connected 
on two streams, and send text out on the first stream, and then 
switch to the second and do nothing, all output from the tnc is 
halted. For example, if I am connected on stream A and B to two 
bbs's, and I am currently on stream A, and I send "1<CR>|B" to list 
all files on the first bbs and then switch my input to the second 
bbs, the tne will halt all output back to me. The results of the 
list command will come back to the tnc, and the tne will receive them 
all internally, but will not send them to the computer....UNTIL I 
sent something to the tne first. (Usually I send "4ck<CR>" to enter 
and then leave command mode. This will then allow all buffered data 
to be sent to me. However, it you do not send anything to the tnc, 
it will send nothing to you. 


I have found these problems by using paket 5.1. Paket creates 

a different window for each of the tnc's streams, and pressing a 
shifted arrow key allows you to switch between the streams. When you 
do this, paKet sends a "|" and the stream identifier. Therefore, it 
is very easy to switch to another stream to view incoming data, 
without wanting to send anything, thus causing the second problem. 
And having entering a command in one window and having the output 
return in another window (the first problem) was also easily 
spotted. I have reproduced these problems using a simple terminal, 
so they are not errors with paket. 


One other note. I have also played with some Kantronics Tnc. They 

do not appear to have the lockup problem, but have an even worse 
version of the first bug. The incoming stream sent from the Kan TNC's 
is only changed when data comes in from over the air, not from 
commands. So if I am on stream A, and switch to stream B, SEND a 
<CR>, (this would fix the TNC2 problem), and start sending commands, 
the tne never send me the stream switch command, so all the feedback 
from my commands always goes to stream A, (or whatever the last 

stream to receive over the air was). This is very frustrating when 
using paket! 


Anyone have any comments on any of this? Has anyone else experienced 
this? Any ideas for solutions? 


Byon Garrabrant KD6BCH byon@csulb.edu 


Date: 28 Feb 94 04:08:32 GMT 

From: nprdc!ihnp4.ucsd.edu!swrinde!cs.utexas.edu!howland.reston.ans.net! 
sol.ctr.columbia.edu!hamblin.math.byu.edu!yvax.byu.edu! sandersm@network.ucsd.edu 
Subject: FT-530 vs TH-78A 


To: 


info-hams@ucsd.edu 


I am debating on wether to buy a Yaesu FT-530 or a Kenwood Th-78A. I would like 


to 


hear experiences from owners of both radios. I am new to this hobby and 


would appreciate any info. 73's TNX Chad 


Date: 28 Feb 94 05:49:10 GMT 

From: nprdc!ihnp4.ucsd.edu!swrinde! gatech!newsxfer.itd.umich.edu! 
elvis.umd.umich.edu! erik@network.ucsd.edu 

Subject: Help!!! Please :) 


To: 


info-hams@ucsd.edu 


i Recently purchased a Kenwood r-5000 general coverage receiver. This 


machine was used so I didn't get a manual....I've figured out everything 
except for probably the most obvious feature....I cannot figure out how 
to set the clock, go figure. If anyone could give me at least a clue, 


it 


would be appreciated. 
Thanks and 73, 


Erik N80LS 


Date: Thu, 3 Mar 1994 15:34:56 GMT 
From: ihnp4.ucsd.edu!swrinde! gatech!wa4mei! ke4zv! gary@network.ucsd.edu 
Subject: Medium range point-to-point digital links 


To: info-hams@ucsd.edu 

In article <CM1inqJ.MBx@srgenprp.sr.hp.com> glenne@sad.hp.com (Glenn Elmore) 
writes: 

[I wrote] 

>> We're dealing with a very sparse matrix here. You don't seem to understand 


>> 
>> 
>> 
>> 
>> 
>> 


that as you sit in a dense metroplex with hams on nearly every block. The 
rest of the country just isn't like that. *xMost*x of our links are 60-80 miles 
long, over unfavorable terrain, to sites we can xgetx. Nearly xnonex of them 
are LOS. We xdepend* on the beyond LOS propagation available most easily at 
lower frequencies to maintain those links. (If we could muster the power to 
do microwave forward scatter, that would be different, but there just aren't 


>> enough surplus TWTs out there to do the job, and site managers frown on 32 ft 
>> dishes on their towers. We xcan't*x depend on inversions and ducts, they just 
>> aren't reliable enough.) 

> 

> At least you and I agree on the need for engineered, reliable links 

>and that construction of a network will take a great deal of 

>cooperation. I've emphasized that one of the few strengths amateur networking 
>xmay*x have is "ins" and access to local sites. All these are 

>points I've tried to make in some of my CNC contributions. 


Yes, but as you indicate below, the sites we xcanx get aren't usually 
sufficient for a LOS network of national scope. I can't emphasize enough 
how xbigx the vacant spaces are between groups of amateur packeteers in 
much of the country, or how unsuited to LOS paths much of the terrain 
separating them is. 


> And in case you think I'm in a densely populated, ideal terrain out here, 
>think again. Mountains only work for you when you can get access and have 
>helpers to maintain them (as you suggest). I end up spending a lot of my time 
>with a 3 arc-second elevation database trying to figure out how to make 

>a well connected network out of sparse users and large obstacles. My few 
>links are (too) long just as you say yours are there. 


Yes, but, for example, there are more hams in LA metro than in all of 
Georgia. Other states are even less densely populated with amateurs 
and/or suitable high sites. This is a source of incredible frustration 
to a potential network designer. 


> My argument with your 56kbps approach is that it simply doesn't come 
>close to being enough capacity. It isn't nearly adequate for the needs 
>of a competetive nationwide amateur network. And, in addition, depending 
>on non-LOS propagation while maintaining reliability is an even less 
>optimum use of resources. 


The only reason I'm pushing 56 kb BLOS links is that I think they're closer 
to *possiblex than microwave LOS links in many cases. I do x*notx say 

we shouldn't use faster links where we can make them work. I just don't 
think that's going to be enough places to fill out the national network. 

I think we're going to have to use beyond LOS paths for a lot of the 

links, just as we do now at 1200 and 9600 baud. If we can upgrade most 

of those to 56 kb, we'll have made a large improvement in the network 
capacity and capability. Now I know that doesn't fullfill your dream 

of a data superhighway, but just as we don't build interstates anymore 
because it's too costly to serve the remaining areas, I think we have 

to scale our network plans to the reality of paved two lane rural highways. 
That's still a big step up from the game trails and dirt ruts we're 

using now. 


> How do you intend to support even a fraction of the "20% of hams who call 
>packet their primary mode" with even *xmediocrex performance (never mind 
>something competetive with telephone line modems which would stimulate and 
>support growth), 50 dB fade margins etc? 


As the telcos know, most traffic is local. Out of LATA traffic is orders 

of magnitude less than what the local switches have to support. I'm talking 
about the out of LATA connectivity here. If a local area can support megabaud+ 
local hubs, great, but for the vast expanses the national net has to cross, 
that's not viable. A 20:1 ratio of intra-LATA to inter-LATA capacity is 
reasonable. 


> You've presented some equations relative to non-quality paths, troposcatter 
>etc, could you show us how a system like that can provide the required 
>total information capacity and approximately what it might cost? 


I'll give a quick cost estimate, about $6 million in capital outlays 

and a continuing site rental of around $1.5 million per year. That'll 
buy us a 47X increase in speed, and a much higher increase in effective 
throughput due to engineered duplex non-contending links, over what we 
have now, and give us the full connectivity that we currently lack. Long 
distance performance will be limited by the network delays and capacity 
limits, but at least it will exist. 


> Could you present an estimation for us all of what the approximate vhf 
>hardware and resulting per-user capacity of a reliable nationwide 
>network of 3000 56 kbps full duplex nodes (your numbers) using beyond 
>LOS propagation might be? Please show not only margins and hardware for 
>an individual link but also an estimate of the spacial and frequency reuse 
>problem/potential. 

> 

> My estimates and opinion of the above indicate that it falls orders of 
>magnitude short of providing service adequate to support itself in an 
>amateur environment. I truly hope you can show me my error(s) and that a 
>beyond-LOS vhf network is viable. 


Well there is an existance proof that beyond LOS VHF networks are viable 

in the amateur community, *xthe existing 1200 baud networksx, and their site 
costs are on the same order as the proposed system. What I'm proposing is 

a dramatic upgrading and expansion, at low UHF, of that system, but with 

the careful engineering and organizational maintenance that the current 
system lacks. No it won't carry long distance digitized voice or video, 

much as I would like that to be true, nor will it allow remote interactive 
logins on a coast to coast basis, but it will allow the movement of Email 
and other bulk data transfers in a timely manner in a way that's completely 
divorced from the commercial communications infrastructure. And higher speed 
links in local areas, xwhere they are viablex, will allow some of those 
advanced features. We just can't support that kind of bandwidth and response 


time on a national basis. Too many sites, too much geography, too few hams. 


Gary 

Gary Coffman KE4ZV 
Destructive Testing Systems 
534 Shannon Way 
Lawrenceville, GA 30244 


You make it, 
we break it. 
Guaranteed! 


gatech!wa4mei! ke4zv! gary 
uunet!rsiatl!ke4zv! gary 
emory!kd4nc!ke4zv! gary 


Date: 3 Mar 94 15:17:27 -0800 

From: news.acns.nwu.edu!math.ohio-state.edu!sdd.hp.com!sgiblab! 
wrdis02.robins.af.mil!apollo.robins.af£.mil!woodj@network.ucsd.edu 
Subject: Nude Radio Amateurs 

To: info-hams@ucsd.edu 


In article <2kti7d$lai@transfer.stratus.com>, 
northup@hoop.sw.stratus.com (Bill Northup) writes: 
> julian@bongo.tele.com (Julian Macassey) writes: 


> 
> The Conservative radio amateurs always make sure they are 
> properly attired before engaging in QSOs. 

> 

> Does this mean that we have to start practicing safe QSOs ? 


Should the prophylactic go over the speaker or the key/microphone?? 
What about safe QSOs on packet!? Cover the the CRT and keyboard??? 
Maybe one big prophylactic covering the antenna would be a cure-all? 
The answer: Abstinence. Result: Less band crowding. :*%) Jim KA4GHX 


Date: Thu, 3 Mar 1994 14:51:46 GMT 
From: netcomsv!netcomsv! bongo! julian@decwrl.dec.com 
To: info-hams@ucsd.edu 


References <1994Mar2.144907.26098@bongo.tele.com>, <CM2960.93I@ucdavis.edu>, 
<213nuj$pr@bigfoot.wustl.edu>e 
Subject : Re: JARGON 


In article <213nuj$pr@bigfoot.wustl.edu> jlw3@cec3.wustl.edu (Jesse L Wei) writes: 
>Now this is my question: do hams xeverx talk about anything besides what 
>kind of rig (s)he's got, ham problems, ham equipment, etc? 


I like to talk about drunkeness, debauchery, politics and 
current affairs. This may be the reason that no one ever talks to me 
on the Los Angeles repeaters. 


Mind you, when I do get technical and say things like "Your 
deviation is low", they offer to change their batteries. 


Julian Macassey, N6ARE julian@bongo.tele.com Voice: (310) 659-3366 
Paper Mail: Apt 225, 975 Hancock Ave, West Hollywood, California 90069-4074 


Date: Thu, 3 Mar 1994 15:30:14 GMT 

From: news.acns.nwu.edu!math.ohio-state.edu!howland.reston.ans.net!gatech! swrinde! 
sgiblab! wetware! spunky.RedBrick.COM!psinntp!psinntp!arrl.org!zlau@network.ucsd.edu 
To: info-hams@ucsd.edu 


References <1994Feb28.154040.17074@ke4zv.atl.ga.us>, 
<1994Feb28.212904.10734@arrl.org>, <1994Mar2.054202.25433@ke4zv.atl.ga.us> 
Subject : Re: Medium range point-to-point digital links 


Gary Coffman (gary@ke4zv.atl.ga.us) wrote: 


: Ah yes, DX Packetcluster. "Hey George, the link's flaky." 
: "Well put up stacked beams and pile on the kilowatts, 
: to hell with the other digital users, the DX spots 

have to get through." (I've actually heard exchanges 
: like that. The lack of cooperation between the Packetcluster 
: operators and the rest of the digital community is somewhat 
: legendary. It's that Type A DXer mentality.) 


Considering what Gary has written, I don't find the lack 
of cooperation a surprise. Nor do I really think it to 
be a problem worth solving, due to the lack of excess 
capacity to be shared. Actually, having a number of 
separate networks may actually be an advantage in an 
emergency, Since the redundancy may help assure that 
something is still working after the disaster strikes. 
It might also be useful for seeing what actually works 
better in the real world. 


BTW--how else does one improve a point to point link, 
besides using bigger antennas and more power? The only 
solutions I can think of are changing frequencies or 
adding sites. Obviously, if there is an interference 
problem, it is easier if the *xotherx guy were to move. 
I don't think there is any disagreement that sites are 
hard to find, which is why I say people should keep an 
open mind and consider a variety of possibilities. 


Zack Lau  KH6CP/1 2 way QRP WAS 
8 States on 10 GHz 
Internet: zlau@arrl.org 10 grids on 2304 MHz 


Date: Thu, 3 Mar 1994 14:41:59 GMT 

From: ihnp4.ucsd.edu!sdd.hp.com! vixen.cso.uiuc.edu!howland.reston.ans.net!gatech! 
wa4mei!ke4zv! gary@network.ucsd.edu 

To: info-hams@ucsd.edu 


References <gradyCLsktB.I3r@netcom.com>, <kmeyer.3bO0x@bbs.xnet.com>, 
<1994Mar2 .175938.12119@alw.nih. gov> 

Reply-To : gary@ke4zv.atl.ga.us (Gary Coffman) 

Subject : Re: Further criminalization of scanning 


In article <1994Mar2.175938.12119@alw.nih.gov> weisen@alw.nih.gov (Neil 
Weisenfeld) writes: 

>Rather than thickening the law books, the government should educate the 
>public about what is going on. The public will demand encrypted 
>cordless phones and the manufacturers will deliver. Then the radio 
>voyeurs have more challenges to liven up the sport :-). All the law is 
>going to do is damage the lives of the very few people who get caught and 
>damage the lives of the many who blab all sorts of confidential information 
>on their cordless phones. 

> 

>I'd be interested if other people agree. 


I agree, both with the idea that government is too quick to say "there 

ought to be a law" and that scanner hobbiests are at heart voyeurs. That's 
where the basic difficulty arises. Laws against Peeping Toms have existed 
for centuries. Congress is trying to extend that principle into the wireless 
age, but they're making the same mistake here as they are with the problem 
of violence in society. Banning scanners will be no more effective than 
banning guns, and has the undesirable side effect of causing unnecessary 
harm to legitimate users of these tools. The real problem in both cases 

is sick and twisted individuals with no sense of morals or ethics, not 

the hardware that enables them to pursue their voyeurism or violence. 


Gary 


Gary Coffman KE4ZV | You make it, | gatech!wa4mei! ke4zv! gary 


Destructive Testing Systems | we break it. | uunet!rsiatl! ke4zv! gary 
534 Shannon Way | Guaranteed! | emory!kd4nc!ke4zv! gary 
Lawrenceville, GA 30244 | 


Date: 3 Mar 94 14:59:41 GMT 
From: yuma! galen@purdue.edu 
To: info-hams@ucsd.edu 


References <CLMqI7.Bvn@murdoch.acc.Virginia.EDU>, 
<9402271401591. gilbaronwOmn.DLITE@delphi.com>, <213360$4jr@news.acns.nwu.edu> 
Subject : Re: Electric Fence RFI/ Liabilities 


>In article <9402271401591.gilbaronwOmn.DLITE@delphi.com>, 
>Gilbert Baron <gilbaronwOmn@delphi.com> wrote: 

>>>I've got some bad interference on 80 through 10 
>>>meter bands from an electric fence about 500 

>>>feet away. The effect is very sharp clicks 

>>>Anyone have any cures? 

>>>Ned Hamilton, AB6FI 


>> 
>>Well, if you ground the fence, case closed. 
>> Gil Baron, El Baron Rojo, WOMN Rochester,MN 


If you disable an electric fence and the livestock gets out and causes 
damage or gets killed, you're in big trouble. Those critters are expensive, 
and if someone hits one with a car... 


If you can wait a few weeks until the grass starts to grow, the livestock 
will get a few zaps, learn about the fence, and I'll bet the owner shuts 
it off. 


It also helps to make sure the fence has good grounds and no partial shorts 
to fence poles, the grass, etc. 


Galen, KFOYI 
I get E-fence I too. 


Date: Thu, 3 Mar 1994 19:55:12 GMT 
From: news.Hawaii.Edu!uhunix3.uhcc.Hawaii.Edu! jherman@ames.arpa 
To: info-hams@ucsd.edu 


References <2k0eup$k30@crcnis1.unl.edu>, 
<rcrw90-180294093408@waters.corp.mot.com.corp.mot.com>, 
<2kcdqj$nto@crcnis1.unl.edu>.uhcc. 


Subject : Re: Keyboards at testing sessions 


In article <2kcdqj$nto@crcnis1.unl.edu> mcduffie@unlinfo.unl.edu (Gary McDuffie 
Sr) writes: 
>rcrw90@email.mot.com (Mike Waters) writes: 


>The need is not to show that someone xis* or xcould* cheat, but for them to 
>prove that they xcould not*x cheat.. If you want to use some piece of 
>equipment in a testing session *xyoux must show that (a) you are not using 
>it to cheat and (b) it won't disturb the other test takers. 


VVVV VV 


>Oh, we are back to guilty_until_proven_innocent now? Be real! 


Gary: I guess you mean to say ‘Be realistic' - not sure what “Be real' means. 
I believe Mike is being realistic - talk to some of the OT VEs about what 
some folks will do, in regards to cheating, in order to pass their test. 


When I give a math exam I have to be quite vigilant in watching my 
students; I've given quite a few Fs over the years to those I've caught 
cheating. The students who've spent many, many hours preparing for an exam 
should not have to share their reward with someone who was irresponsible 
in their studies, whether it's a government radio exam or math exam. 


Jeff 


Jeffrey Herman NH6IL jherman@hawaii.edu, who, in his spare time, cannibalizes 
old TV sets to make QRPp transmitters (CW, of course). 


Previously: WA6QIJ, WH6AEQ, NMO (U.S. Coast Guard Radio Honolulu: 500 kc CW) 
NMC6 (U.S, Coast Guard Group Monterey) 


Vietnamese Proverb: If you study you will become what you wish 
If you do not study you will never become anything. 


Date: Thu, 3 Mar 1994 19:10:07 GMT 

From: news.acns.nwu.edu!math.ohio-state.edu!howland.reston.ans.net! 
vixen.cso.uiuc.edu!sdd.hp.com!sgiblab!sgigate.sgi.com!odin!chuck.dallas.sgi.com! 
adams@network.ucsd.edu 

To: info-hams@ucsd.edu 


References <14@ted.win.net><CLwqAH.LHE@odin.corp.sgi.com>, <110@ted.win.net>, 
<CM3nI1.79r@odin.corp.sgi.com> 


Subject : Re: 40 meter QRP (cw or ssb) 


In article <110@ted.win.net>, mjsilva@ted.win.net (Michael Silva) writes: 
...stuff deleted... 

|> >World Record is 75.2 WPM. It will not stand for much longer. 

...more stuff deleted... 

|> Why won't it stand much longer? 

|> 

|> 

|> Mike, KK6GM 

|> 

|> 


it should be broken by one or more people within the next year. 
my prediction. 


dit dit 


Chuck Adams K5FO CP-60 
adams@sgi.com 


End of Info-Hams Digest V94 #234 
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